The term "method" has a commonly understood meaning within the field of object-oriented computer program development and another, albeit different meaning, in the field of patent law. To avoid confusion, the following description will use the term "method" as typically understood within the field of object-oriented computer programming. The term "process" will be used as an expression of a "method of doing something," that is, in the sense of performing a series of operations that comprise a patentable "process."
As shown in FIG. 1 a typical computer (or computer system) 100 is comprised of a processor 105 device, working memory 110 (often referred to as random access memory or RAM), one or more long-term storage devices 115 (such as, for example, magnetic hard and floppy disks, magnetic tape units, and optical disks), a display unit 120, and an input device such as, for example, a keyboard 125. As would be known to those of ordinary skill, long-term storage devices 115 are used to store programs 130 that are loaded into memory 110 prior to the program's execution by the processor 105. One illustrative program 130 is a compiler program.
Consider the compilation of a computer program written in the "OBJECTIVE-C" programming language and having multiple source-code files. In the illustrative example shown in FIG. 2, a program 200 is comprised of two source-code files, file1.m 205 and file2.m 210 respectively. As shown, each source-code file contains a plurality of method call instructions. When the method call a x! is executed at run-time, it invokes a method named "x" in an instance of a class named "a," where "x" is a string value referred to as a method selector or, alternatively, a method name string.
During program 200 compilation, an "OBJECTIVE-C" compiler program, referred to simply as a compiler, generates an object-code file for each source-code module, where a source-code module comprises a specific source-code file (e.g., file1.m 205) and any additional files included in the specified source-code file such as, for example, by the "#include" directive. (Those of ordinary skill will recognize that the actual compiler operations are performed by a suitable computer system that reads the instructions and/or data of the compiler program from a program storage device and executes the instructions.)
As shown in FIG. 3, each object-code file contains, among other things, a local name table that has a pointer to every method selector used in a method call in the source-code module. Thus, file1.o 300 contains local name table 1 305 having entries that point to every method selector used in a method call instruction in file1.m 205. A similar object-code file is generated for source-code file file2.m 210, see elements 310 and 315.
Referring again to FIGS. 2 and 3, when the compiler parses the method call a x ! from source-code file1.m 205, it generates executable instructions to perform the following operations:
Step 1: Load a pointer to the instance of the object `a` into a first specified register of the processor executing the program (the value `a` represents an object type identifier). PA0 Step 2: Load a pointer to the local name table 305 associated with the method call. PA0 Step 3: Modify the value of the pointer loaded in step 2 to account for the offset into the local name table 305 at which the string variable "x" (method selector) is located. PA0 Step 4: Generate an instruction to call a standard method dispatch function such as, for example, MessageSend. As would be known to those of ordinary skill, the dispatch function MessageSend is responsible, at program run-time, for locating the executable code segment associated with the method being called, method "x." (The pointer value loaded in step 1 is MessageSend's first parameter and the pointer value loaded in step 2 is MessageSend's second parameter.)
As made clear by steps 2 and 3 above, compilation of a (source-code) method call generates two machine executable instructions, implementing an indirect addressing technique to identify a target method selector. One instruction loads a pointer to the method call's local name table (step 2 above) and the other adjusts that pointer so that it points to the precise method selector being invoked (step 3 above).
Following compilation, a linker is used to generate a single executable file that includes, among other things, substantially each object-code file. As shown in FIG. 4, an executable file 400 contains local name table 1 305 from file1.o 305 and local name table 2 315 from file2.o 310. Those of ordinary skill in the art will recognize that object-code files 300 and 310 also contain code segments and global data information and that this information is also incorporated into the executable file 400. See elements 405 and 410. Thus, a typical link operation generates an executable file that can contain multiple copies of any given method selector. In fact, anytime a method selector is used in a method call in more than a single source-code file, the resulting executable file will contain multiple copies of that method selector.
At execution time, a run-time library is used to load a copy of the executable file 400 into working memory, at which point it is referred to as an executable image 500 (see FIG. 5), whereafter method selector unification is performed. Following method selector unification, the executable code consisting of the compiled, linked, and loaded program is executed.
As would be known to those of ordinary skill in the art, the purpose of method selector unification is to ensure that all references to a specified method selector (in the executable image), regardless of which local name table the original reference is found in, point to a common string value. In general, method selector unification proceeds in the following fashion. First, each local name table in the executable image 500 is interrogated and a selector table 505 is created. The selector table 505 is often implemented as a hash table, having one entry for each unique method selector found in the executable image's method name tables. Next, each pointer in each local name table is modified to point to that entry in the selector table 505 that corresponds to the same method selector.
Referring again to FIG. 5, for example, local name table 1's 305 pointer to method selector `x` 510 and local name table 2's 315 pointer to method selector `x` 515 are consolidated (unified) in the executable image's 500 selector table 505 as a single pointer 520. Following method selector unification the run-time library begins executing the machine instructions contained in the executable image 500.
A known benefit of postponing method selector unification until program execution is that it allows a program to load, at run-time, an object module (an object-code file such as 300 or 310) that can override a previously compiled-and-linked method definition. A known drawback to this approach is that, because the compiler is limited only to referencing local name tables, it must generate instructions to implement an indirect addressing scheme as described in steps 2 and 3 above.